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Abstract. In answer-set programming (ASP), the solutions of a problem are encoded in dedicated 
models, called answer sets, of a logical theory. These answer sets are computed from the program that 
represents the theory by means of an ASP solver and returned to the user as sets of ground first-order 
literals. As this type of representation is often cumbersome for the user to interpret, tools like ASPVI Z 
and IDPDraw were developed that allow for visualising answer sets. The tool Kara, introduced in 
this paper, follows these approaches, using ASP itself as a language for defining visualisations of 
interpretations. Unlike existing tools that position graphic primitives according to static coordinates 
only, Kara allows for more high-level specifications, supporting graph structures, grids, and relative 
positioning of graphical elements. Moreover, generalising the functionality of previous tools, Kara 
provides modifiable visualisations such that interpretations can be manipulated by graphically editing 
their visualisations. This is realised by resorting to abductive reasoning techniques. Kara is part of 
SeaLion, a forthcoming integrated development environment (IDE) for ASP. 

1 Introduction 

Answer-set programming (ASP) [1] is a well-known paradigm for declarative problem solving. Its key idea 
is that a problem is encoded in terms of a logic program such that dedicated models of it, called answer 
sets, correspond to the solutions of the problem. Answer sets are interpretations, usually represented by 
sets of ground first-order literals. 

A problem often faced when developing answer-set programs is that interpretations returned by an ASP 
solver are cumbersome to read — in particular, in case of large interpretations which are spread over several 
lines on the screen or the output file. Hence, a user may have difficulties extracting the information he or 
she is interested in from the textual representation of an answer set. Related to this issue, there is one even 
harder practical problem: editing or writing interpretations by hand. 

Although the general goal of ASP is to have answer sets computed automatically, we identify different 
situations during the development of answer-set programs in which it would be helpful to have adequate 
means to manipulate interpretations. First, in declarative debugging [2], the user has to specify the seman- 
tics he or she expects in order for the debugging system to identify the causes for a mismatch with the 
actual semantics. In previous work [3], a debugging approach has been introduced that takes a program P 
and an interpretation I that is expected to be an answer set of P and returns reasons why / is not an answer 
set of P. Manually producing such an intended interpretation ahead of computation is a time-consuming 
task, however. Another situation in which the creation of an interpretation can be useful is testing post- 
processing tools. Typically, if answer-set solvers are used within an online application, they are embedded 
as a module in a larger context. The overall application delegates a problem to the solver by transforming it 
to a respective answer-set program and the outcome of the solver is then processed further as needed by the 
application. In order to test post-processing components, which may be written by programmers unaware 
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Fig. 1. Overview of the workflow (visualisation and abduction process). 



of ASP, it would be beneficial to have means to create mock answer sets as test inputs. Third, the same idea 
of providing test input applies to modular answer-set programming [4], when a module B that depends 
on another module A is developed before or separately from A. In order to test B, it can be joined with 
interpretations mocking answer sets from A. 

In this paper, we describe the system Kara which allows for both visualising interpretations and editing 
them by manipulating their visualisations. 3 The visualisation functionality of Kara has been inspired by 
the existing tools ASPVIZ [5] and IDPDraw [6] for visualising answer sets. The key idea is to use ASP 
itself as a language for specifying how to visualise an interpretation /. To this end, the user takes a dedicated 
answer-set program V — which we call a visualisation program — that specifies how the visualisation of / 
should look like. That is, V defines how different graphical elements, such as rectangles, polygons, images, 
graphs, etc., should be arranged and configured to visually represent /. 

Kara offers a rich visualisation language that allows for defining a superset of the graphical elements 
available in ASPVIZ and IDPDraw, e.g., providing support for automatically layouting graph structures, 
relative and absolute positioning, and support for grids of graphical elements. Moreover, Kara also offers 
a generic mode of visualisation, not available in previous tools, that does not require a domain-specific 
visualisation program, representing an answer set as a hypergraph whose set of nodes corresponds to the 
individuals occurring in the interpretation. 4 A general difference to previous tools is that Kara does not 
just produce image files right away but presents the visualisation in form of modifiable graphical elements 
in a visual editor. The user can manipulate the visualisation in various ways, e.g., change size, position, or 
other properties of graphical elements, as well as copy, delete, and insert new graphical elements. Notably, 
the created visualisations can also be used outside our editing framework, as Kara offers an SVG export 
function that allows to save the possibly modified visualisation as a vector graphic. Besides fine-tuning 
exported SVG files, manipulation of the visualisation of an interpretation I can be done for obtaining a 
modified version /' of / by means of abductive reasoning [7]. This gives the possibility to visually edit 
interpretations which is useful for debugging and testing purposes as described above. 

In Section 3, we present a number of examples that illustrate the functionality of Kara and the ease of 
coping with a visualised answer set compared to interpreting its textual representation. 

Kara is designed as a plugin of SeaLion, an Eclipse-based integrated development environment 
(IDE) for ASP [8] that is currently developed as part of a project on programming-support methods for 
ASP [9]. 



2 System Overview 

We assume familiarity with the basic concepts of answer-set programming (ASP) (for a thorough introduc- 
tion to the subject, cf. Baral [1]). In brief, an answer-set program consists of rules of the form 

oi V • • • V ai : - aj+i, . . . , a m , not a m+ i, . . . , not a„, 

3 The name "Kara" derives, with all due respect, from "Kara Zor-El", the native Kryptonian name of Supergirl, given 
that Kryptonians have visual superpowers on Earth. 

4 A detailed overview of the differences concerning the visualisation capabilities of Kara with other tools is given in 
Section 4. 
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Fig. 2. The visualisation of interpretation / from Example 1 . 

where n > m > I > 0, "not" denotes default negation, and all aj are first-order literals (i.e., atoms 
possibly preceded by the strong negation symbol, -i). For a rule r as above, we define the head of r as 
H(r) = {a l7 . . . , ai} and the positive body as B + (r) = {aj+i, . . . , a m }. If n = Z = 1, r is a fact, and if 
Z = 0, r is a constraint. For facts, we will usually omit the symbol ": — ". The grounding of a program 
P relative to its Herbrand universe is defined as usual. An interpretation I is a finite and consistent set of 
ground literals, where consistency means that {a, ^a} % I, for any atom a. I is an answer set of a program 
P if it is a minimal model of the grounding of the reduct of P relative to I (see Baral [1] for details). 

The overall workflow of Kara is depicted in Fig. 1, illustrating how an interpretation I can be visualised 
in the upper row and how changing the visualisation can be reflected back to I such that we obtain a 
modified version /' of I in the lower row. In the following, we call programs that encode problems for 
which / and I' provide solution candidates domain programs. 

2.1 Visualisation of Interpretations 

As discussed in the introduction, we use ASP itself as a language for specifying how to visualise an inter- 
pretation. In doing so, we follow a similar approach as the tools ASPVIZ [5] and IDPDraw [6]. We next 
describe this method on an abstract level. 

Assume we want to visualise an interpretation I that is defined over a first-order alphabet A. We join 
/, interpreted as a set of facts, with a visualisation program V that is defined over A' D A, where A' may 
contain auxiliary predicates and function symbols, as well as predicates from a fixed set V v of reserved 
visualisation predicates that vary for the three tools. 5 

The rules in V are used to derive different atoms with predicates from V v , depending on /, that control 
the individual graphical elements of the resulting visualisation including their presence or absence, position, 
and all other properties. An actual visualisation is obtained by post-processing an answer set I v of V U / 
that is projected to the predicates in V v . We refer to I v as a visualisation answer set for /. The process 
is depicted in the upper row of Fig. 1. An exhaustive list of visualisation predicates available in Kara is 
given in Appendix A. 

Example 1. Assume we deal with a domain program whose answer sets correspond to arrangements of 
items on two shelves. Consider the interpretation I = {book{s\, 1), book{s\, 3), book(s 2 , 1), globe(s2, 2)} 
stating that two books are located on shelf s\ in positions 1 and 3 and that there is another book and a globe 
on shelf s 2 in positions 1 and 2. The goal is to create a simple graphical representation of this and similar 
interpretations, depicting the two shelves as two lines, each book as a rectangle, and globes as circles. 
Consider the following visualisation program: 



visline(shelf 1 , 10, 40, 80, 40, 0). (1) 

visline(shelf 2 , 10, 80, 80, 80, 0). (2) 

visrect{f{X, Y), 20, 8) : - book(X, Y). (3) 

visposition(f (s!,Y), 20 *Y,20,0) :- book(si,Y). (4) 

msposition(f(s 2 ,Y),20*Y,60,0) :- book(s 2 ,Y). (5) 

visellipse(f(X,Y), 20,20) :- globe{X,Y). (6) 

visposition{f {si_,Y), 20 *Y,20,0) : - globe{s u Y). (7) 

visposition(f (s 2 ,Y), 20 *Y, 60,0) :- globe(s2, Y). (8) 



5 Technically, in ASPVIZ, V is not joined with / but with a domain program P such that / is an answer set of P. 



Rules (1) and (2) create two lines with the identifiers shelf \ and shelf 2 , representing the top and bottom 
shelf. The second to fifth arguments of visline / 6 represent the origin and the target coordinates of the line. 6 
The last argument of visline/ 6 is a z-coordinate determining which graphical element is visible in case 
two or more overlap. Rule (3) generates the rectangles representing books, and Rules (4) and (5) determine 
their position depending on the shelf and the position given in the interpretation. Likewise, Rules (6) to (8) 
generate and position globes. The resulting visualisation of I is depicted in Fig. 2. □ 

Note that the first argument of each visualisation predicate is a unique identifier for the respective 
graphical element. By making use of function symbols with variables, like f(X, Y) in Rule (3) above, these 
labels are not limited to constants in the visualisation program but can be generated on the fly, depending 
on the interpretation to visualise. While some visualisation predicates, like visline, visrect, and visellipse, 
define graphical elements, others, e.g., visposition, are used to change properties of the elements, referring 
to them by their respective identifiers. 

Kara also offers a generic visualisation that visualises an arbitrary interpretation without the need for 
defining a visualisation program. In such a case, the interpretation is represented as a labelled hypergraph. 
Its nodes are the individuals appearing in the interpretation and the edges represent the literals in the 
interpretation, connecting the individuals appearing in the respective literal. Integer labels on the endings 
of the edge are used for expressing the term position of the individual. To distinguish between different 
predicates, each edge has an additional label stating the predicate. Edges of the same predicate are of the 
same colour. A generic visualisation is presented in Example 4. 

2.2 Editing of Interpretations 

We next describe how we can obtain a modified version /' of an interpretation / corresponding to a manip- 
ulation of the visualisation of /. We follow the steps depicted in the lower row of Fig. 1, using abductive 
reasoning. Recall that abduction is the process of finding hypotheses that explain given observations in the 
context of a theory. Intuitively, in our case, the theory is the visualisation program, the observation is the 
modified visualisation of /, and the desired hypothesis is 

In Kara, the visualisation of / is created using the Graphical Editing Framework (GEF) [10] of Eclipse. 
It is displayed in a graphical editor which allows for various kinds of manipulation actions such as mov- 
ing, resizing, adding or deleting graphical elements, adding or removing edges between them, editing their 
properties, or change grid values. Each change in the visual editor of Kara is internally reflected by a mod- 
ification to the underlying visualisation answer set I v . We denote the resulting visualisation interpretation 
by I' v . From that and the visualisation program V, we construct a logic program X(I' V , V) such that the 
visualisation of any answer set /' of X(I' V , V) using V corresponds to the modified one. 

The idea is that X(I' V , V), which we refer to as the abduction program for I' v and V, guesses a set 
of abducible atoms. On top of these atoms, the rules of V are used in X(I' V , V) to derive a hypothetical 
visualisation answer set I" for /'. Finally, constraints in the abduction program ensure that I" coincides 
with the targeted visualisation interpretation I' v on a set Vi of selected predicates from V v , which we call 
integrity predicates. Hence, a modified interpretation I' can be obtained by computing an answer set of 
X(I' V ,V) and projecting it to the guessed atoms. To summarise, the abduction problem underlying the 
described process can be stated as follows: 

(*) Given the interpretation I' v , determine an interpretation /' such that I' v coincides with each answer set 
of VUl' on Vi. 

Clearly, visualisation programs must be written in a way that manipulated visualisation interpretations 
could indeed be the outcome of the visualisation program for some input. This is not the case for arbitrary 
visualisation programs, but usually it is easy to write an appropriate visualisation program that allows for 
abducing interpretations. 

The following problems have to be addressed for realising the sketched approach: 

- determining the predicates and domains of the abducible atoms, and 

6 The origin of the coordinate system is at the top-left corner of the illustration window with the x-axis pointing to 
the right and the t/-axis pointing down. 



dom(I' v , V) = {nonRecDom(t) :-v(t') \ r G V,v/m G V v ,v(t') G H(r), 
o(t) G B+(r),t = ti,...,t,...,t n ,a/n $ V v , 
VAR(t) 0, Vtt.R(i) C KAR(t')}U 

{dom(i) :— w(t'), nonRecDom(Xi) , . . . , nonRecDom(Xi) \ r £ V, 
v/me T v ,v(t') e R(r),a(t) G B+(r), t = ti, . . . , t, . . . , t n , 
a/n $ V v , VAR(t) n VAR(t') / 0, 
VAR(t) \ VAR(t') = {X 1 ,...,X l }}U 

{dom(X) : — nonRecDom(X)} , 

guess(V) = {a(Xi, . . . ,X„) :— not -ia(Xi, . . . ,X n ), dom(X\), dom{X n ), 
-io(Xi, . . . , X n ) : — not a(Xi, . . . ,X n ), dom(Xi), dom(X n ) \ 
a/n $ V v ,a(ti,. • • , t„) G (J re v B W, 
{a(tl,...,0 | a(t[, . . . , t' n ) G H(r), r £ V} — 0}, 

check(4) = {:- not v(ti, . . . , t n ), :- v(Xi, . . . ,X„),not v'(Xi, X„), 
v'(ti,. ..,t„) | v(ti, ...,*„) e I' v ,v/n G P*}, 



Fig. 3. Elements of the abduction program A(/£, V). 

- choosing the integrity predicates among the visualisation predicates. 

For solving these issues, we rely on pragmatic choices that seem useful in practice. We obtain the set V a of 
predicates of the abducible atoms from the visualisation program V. The idea is that every predicate that 
is relevant to the solution of a problem encoded in an answer set has to occur in the visualisation program 
if the latter is meant to provide a complete graphical representation of the solution. Moreover, we restrict 
V a to those non-visualisation predicates in V that occur in the body of a rule but not in any head atom in 
V. The assumption is that atoms defined in V are most likely of auxiliary nature and not contained in a 
domain program. 

An easy approach for generating a domain V a of the abducible atoms would be to extract the terms 
occurring in I' v . We follow, however, a more fine-grained approach that takes the introduction and deletion 
of function symbols in the rules in V into account. Assume V contains the rules 

visrect(f (Street, Num), 9,10) : — house(Street, Num) and 
visellipse(sun, Width, Height) :— property (sun, size(Width, Height)), 

and V v contains visrect(j (baker street , 2216), 9, 10) and visellipse(sun, 10,11). Then, when extracting 
the terms in I' v , the domain includes / (baker street, 2216), bakerstreet, 2216, 9, 10, sun, and 11 for the 
two rules. However, the functor / is solely an auxiliary concept in V and not meant to be part of domain 
programs. Moreover, the term 9 is introduced in V and is not needed in the domain for Also, the terms 
10 and 11 as standalone terms and sun are not needed in /' to derive I' v . Even worse, the term size(10, 11), 
that has to be contained in /' such that I' v can be a visualisation answer set for is missing in the domain. 
Hence, we derive V a in \(I' V , V) not only from I' v but also consider the rules in V. Using our translation 
that is detailed below, we obtain bakerstreet, 2216, and size(10, 12) as domain terms from the rules above. 

For the choice of Vi, i.e., of the predicates on which I' v and the actual visualisation answer sets of /' 
need to coincide, we exclude visualisation predicates that require a high preciseness in visual editing by 
the user in order to match exactly a value that could result from the visualisation program. For example, we 
do not include predicates determining position and size of graphical elements, since in general it is hard to 
position and scale an element precisely such that an interpretation /' exists with a matching visualisation. 
Note that this is not a major restriction, as in general it is easy to write a visualisation program such that 
aspects that the user wants to be modifiable are represented by graphical elements that can be elegantly 
modified visually. For example, instead of representing a Sudoku puzzle by labels whose exact position is 
calculated in the visualisation program, the language of Kara allows for using a logical grid such that the 
value of each cell can be easily changed in the visual editor. 

We next give the details of the abduction program. 



Definition 1. Let I' v be an interpretation with atoms over predicates in V v , V a (visualisation) program, 
and Vi C V v the fixed set of integrity predicates. Moreover, let VAR(T) denote the variables occurring in 
T, where T is a term or a list of terms. Then, the abduction program with respect to I' v and V is given by 

\{I' V , V) = dom(4, V) U guess(V) U7U check(%), 

where dom(/(,, V), guess(V), and check(Z^) are given in Fig. 3, and nonRecDom/1, dom/l, and v' /n, 
for all v/n e Vi, are fresh predicates. 

The idea of dom(I' v , V) is to consider non-ground terms t contained in the body of a visualisation rule that 
share variables with a visualisation atom in the head of the rule and to derive instances of these terms when 
the corresponding visualisation atom is contained in I' v . In case less variables occur in the visualisation 
atom than in t, we avoid safety problems by restricting their scope to parts of the derived domain. Here, 
the distinction between predicates dom and nonRecDom is necessary to prevent infinite groundings of 
the abduction program. Note that in general it is not guaranteed that the domain we derive contains all 
necessary elements for abducing an appropriate interpretation For instance, consider the case that the 
visualisation program contains a rule visrect(id, 5,5) : — foo(X), and V together with the constraints in 
check(I' v ) require that for all terms t of a domain that can be obtained from I' v and V, foo(t) must not hold. 
Then, there is no interpretation that will trigger the rule using this domain, although an interpretation with 
a further term t' might exist that results in the desired visualisation. Hence, we added an editor to Kara 
that allows for changing and extending the automatically generated domain as well as the set of abducible 
predicates. 

The following result characterises the answer sets of the abduction program. 

Theorem 1. Let I' v be an interpretation with atoms over predicates in V v , V a (visualisation) program, 
and Vi C V v the fixed set of integrity predicates. Then, any answer set I" of X(I' V , V) coincides with I' v on 
the atoms over predicates from Vi, and a solution I' of the abduction problem (*) is obtained from I" by 
projection to the predicates in 

{a/n | a(ti, . . . , t n ) e (J B(r), {a(t' lt . . . ,t' n ) | a(t[, . . . , t'J e H(r), r &V} = $}\V V . 
rev 



2.3 Integration in SeaLion 

Kara is written in Java and integrated in the Eclipse-plugin SeaLion [8] for developing answer-set pro- 
grams. Currently, it can be used with answer-set programs in the languages of Gringo and DLV. SeaLion 
offers functionality to execute external ASP solvers on answer-set programs. The resulting answer sets can 
be parsed by the IDE and displayed as expandable tree structures in a dedicated Eclipse view for interpreta- 
tions. Starting from there, the user can invoke Kara by choosing a pop-up menu entry of the interpretation 
he or she wants to visualise. A run configuration dialog will open that allows for choosing the visualisation 
program and for setting the solver configuring to be used by Kara. Then, the visual editor opens with the 
generated visualisation. The process for abducing an interpretation that reflects the modifications to the 
visualisation can be started from the visual editor's pop-up menu. If a respective interpretation exists, one 
will be added to SeaLion's interpretation view. 

The sources of Kara and the alpha version of SeaLion can be downloaded from 

http : //sourcef orge . net /pro jects/mmdasp/. 

An Eclipse update site will be made available as soon as SeaLion reaches beta status. 

3 Examples 

In this section, we provide examples that give an overview of Kara's functionality. We first illustrate the 
use of logic grids and the visual editing feature. 



visgrid(maze, MAXR, MAXC, MAXR*20+5, MAXC*20+5):- rnaxC(MAXC), maxR(MAXR). (9) 



visposition(maze, 0, 0, 0). (10) 

%A cell with a wall on it. 

visrect (wall, 20, 20). (11) 

visbackgroundcolor(wall, black). (12) 

% An empty cell. 

visrect(empty, 20, 20). (13) 

visbackgroundcolor (empty , white). (14) 

viscolor (empty, white). (15) 

% Entrance and exit . 

visimage (entrance, " entrance.jpg"). (16) 

visscale(entrance, 18, 18). (17) 

visimage(exit, "exit.png"). (18) 

visscale(exit, 18, 18). (19) 

% Filling the cells of the grid. 

visfillgrid(maze, empty, R,C) : — empty(C, R), not entrance(C, R), not exit(C, R). (20) 

visfillgrid(maze, wall, R,C) :— wall(C, R), not entrance(C, R), not exit(C, R). (21) 

visfillgrid(maze, entrance, R,C) :— entrance(C, R). (22) 

visfillgrid(maze, exit,R,C) : — exit(C,R). (23) 

% Vertical and horizontal lines . 

wsKne(t;(0), 5, 5, 5, M/lXi? * 20 + 5, 1) : - maxR(MAXR). (24) 

OTsfo2e(w(C), C*20+5, 5, C*20+5, M/lXi?*20+5, 1) : - co/(C), maxR(MAXR). (25) 

vtshne(h(0), 5, 5, M^XC * 20 + 5, 5, 1) : - maxC(MAXC). (26) 

visUne(h(R), 5, * 20 + 5, M/1XC * 20 + 5, i? * 20 + 5, 1) : - row(R), maxC(MAXC). (27) 

% Define possible grid values for editing. 

vispossiblegridvalues(maze, wall). (28) 

vispossiblegridvalues(maze, empty). (29) 

vispossiblegridvalues(maze, entrance). (30) 

vispossiblegridvalues(maze, exit). (31) 



Fig. 4. Visualisation program for Example 2. 



Example 2. Maze-generation is a benchmark problem from the second ASP competition [11]. The task is to 
generate a two-dimensional grid, where each cell is either a wall or empty, that satisfies certain constraints. 
There are two dedicated empty cells, being the maze's entrance and its exit, respectively. The following 
facts represent a sample answer set of a maze generation encoding restricted to interesting predicates. 

co/(1..5). row(1..5). maxC(5). maxR(b). wall(l,l). empty(l,2). wall(l,3). 
wall(l,4). wall(l,5). wall(2,l). empty(2,2). empty(2,3). empty(2,4). wall(2,h). 
wall(2>,l). wall(3,2). wall(3,3). empty(3,4). wall(3,5). wall(A,l). empty(4,2). 
empty(4:,3). empt?/(4,4). wall(A, 5). wall(5, 1). wall(5, 2). wall(5,3). empty(5,4:). 
wall(5,5). entrance(l,2). exit(5,4). 

Predicates col/1 and row/1 define indices for the rows and columns of the maze, while maxC/1 
and maxR/1 give the maximum column and row number, respectively. The predicates wall/ 2, empty / 2, 
entrance/ 2, and exit/ 2 determine the positions of walls, empty cells, the entrance, and the exit in the grid, 
respectively. One may use the visualisation program from Fig. 4 for maze-generation interpretations of this 
kind. 

In Fig. 4, Rule (9) defines a logic grid with identifier maze, MAXR rows, and MAXC columns. The 
fourth and fifth parameter define the height and width of the grid in pixel. Rule (10) is a fact that defines 
a fixed position for the maze. The next step is to define the graphical objects to be displayed in the grid. 
Because these objects are fixed (i.e., they are used more than once), they can be defined as facts. A wall is 




Fig. 5. Visualisation output for the maze-generation program. 



represented by a rectangle with black background and foreground colour 7 (Rules (11) and (12)) whereas an 
empty cell is rendered as a rectangle with white background and foreground colour (Rules (13) to (15)). The 
entrance and the exit are represented by two images (Rules (16) to (19)). Then, these graphical elements 
are assigned to the respective cell of the grid (Rules (20) to (23)). Rules (24) to (27) render vertical and 
horizontal lines to better distinguish between the different cells. Rules (28) to (31) are not needed for 
visualisation but define possible values for the grid that we want to be available in the visual editor. 

Once the grid is rendered, the user can replace the value of a cell with a value defined using predicate 
vispossiblegridvalues /2 (e.g., replacing an empty cell with a wall). The visualisation of the sample inter- 
pretation using this program is given in Fig. 5. Note that the visual representation of the answer set is much 
easier to cope with than the textual representation of the answer set given in the beginning of the example. 

Next, we demonstrate how to use the visual editing feature of Kara to obtain a modified interpretation, 
as shown in Fig. 6. Suppose we want to change the cell (3, 2) from being a wall to an empty cell. The user 
can select the respective cell and open a pop-up menu that provides an item for changing grid-values. A 
dialog opens that allows for choosing among the values that have been defined in the visualisation program, 
using the vispossiblegridvalues / 2 predicate. When the user has finished editing the visualisation, he or she 
can start the abduction process for inferring the new interpretation. When an interpretation is successfully 
derived, it is added to SeaLion's interpretation view. □ 

Kara supports absolute and relative positioning of graphical elements. If for any visualisation element 
the predicate visposition /4 is defined, then we have fixed positioning. Otherwise, the element is positioned 
automatically. Then, by default, the elements are randomly positioned on the graphical editor. However, the 
user can define the position of an element relative to another element. This is done by using the predicates 

visleft/2, visright/2, visabove/2, visbelow /2, and visinfrontof /2. 

Example 3. The following visualisation program makes use of relative positioning for sorting elements 
according to their label. 



visrect(a, 50, 50) 
vislabel(a, laba). 
vistext(laba, 3). 



(32) 
(33) 
(34) 

(35) 
(36) 
(37) 
(38) 
(39) 



vispolygon(b, 0, 20, 1). 
vispolygon{b, 25, 0, 2). 
vispolygon{b, 50, 20, 3). 



vislabel(b, labb). 
vistext(labb, 10). 



visellipse(c, 30, 30). 



(40) 
(41) 
(42) 



vislabel(c, labc). 
vistext(labc, 5). 



element(X) : — visrect(X,_, _). 
element(X) : — vispolygon(X, _, _, _). 
element(X) :— visellipse(X, _, _). element 



(43) 
(44) 
(45) 



7 Black foreground colour is default and may not be set explicitly. 
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visleft(X,Y) : — element (X), element(Y), vislabel(X, LABX), 

vistext{LABX , XNUM), vislabel{Y, LABY), (46) 
vistext(LABY . YNUM),XNUM < YNUM . 

The program defines three graphical objects, a rectangle, a polygon, and an ellipse. In Rules (32) to (34), 
the rectangle together with its label 3 is generated. The shape of the polygon (Rules (35) to (37)) is defined 
by a sequence of points relative to the polygon's own coordinate system using the vispolygon / A predicate. 
The order in which these points are connected with each other is given by the predicate's fourth argument. 
Rules (38) and (39) generate the label for the polygon and specify its text. Rules (43) to (45) state that every 
rectangle, polygon, and ellipse is an element. The relative position of the three elements is determined by 
Rule (46). For two elements E\ and E 2 , E\ has to appear to the left of E 2 whenever the label of E\ 
is smaller than the one of E\. The output of this visualisation program is given in Fig. 7. Note that the 
visualisation program does not make reference to predicates from an interpretation to visualise, hence the 
example illustrates that Kara can also be used for creating arbitrary graphics. □ 

The last example demonstrates the support for graphs in Kara. Moreover, the generic visualisation 
feature is illustrated. 

Example 4. We want to visualise answer sets of an encoding of a graph-colouring problem. Assume we 
have the following interpretation that defines nodes and edges of a graph as well as a colour for each node. 

\node(\), node (2), node(3), node(A), node(b), node(6), edge(l,2), edge(l,3), 
edge(l,A), edge(2,A), edge(2,5), edge(2,6), edge(?>,l), ed^e(3,4), edge(3, 5), 
edge(4, 1), edge{A, 2), edge(5, 3), edge(5,4), edge(5,6), edge(6,2), edge(6,3), 
edge(6,5), color (1, lightblue), color '(2, yellow), color (3, yellow), color (A, red), 
color(5, lightblue), color(6, red)}. 



We make use of the following visualisation program: 




Fig. 7. Output of the visualisation program in Example 3. 



% Generate a graph. 
visgraph(g). (47) 

% Generate the nodes of the graph. 
visellipse(X, 20, 20) : - node(X). (48) 
visisnode(X , g) : — node(X). (49) 

% Connect the nodes (edges of the input) . 

visconnect{f(X, Y),X, Y) : — edge(X, Y). (50) 
vistargetdeco(X, arrow) : — visconnect(X, _,_). (51) 

% Generate labels for the nodes. 

vislabel (X,l(X)):- node (X) . (52) 

vistext{l{X),X) :- node(X). (53) 

visfontstyle(l(X), bold) : — node(X). (54) 

% Color the node according to the solution. 
visbackgroundcolor(X, COLOR) : — node(X), color(X, COLOR). (55) 



In Rule (47), a graph, g, is defined and a circle for every node from the input interpretation is created 
(Rule (48)). Rule (49) states that each of these circles is logically considered a node of graph g. This has 
the effect that they will be considered by the algorithm layouting the graph during the creation of the 
visualisation. The edges of the graph are defined using the visconnect/3 predicate (Rule (50)). It can be 
used to connect arbitrary graphical elements with a line, also if they are not nodes of some graph. As we 
deal with a directed graph, an arrow is set as target decoration for all the connections (Rule (51)). Labels 
for the nodes are set in Rules (52) to (54). Finally, Rule (55) sets the colour of the node according to the 
interpretation. The resulting visualisation is depicted in Fig. 8. Moreover, the generic visualisation of the 
graph colouring interpretation is given in Fig. 9. □ 



4 Related Work 

The visualisation feature of Kara follows the previous systems ASPVIZ [5] and IDPDraw [6], which also 
use ASP for defining how interpretations should be visualised. 8 Besides the features beyond visualisation, 
viz. the framework for editing visualisations and the support for multiple solvers, there are also differences 
between Kara and these tools regarding visualisation aspects. 

Kara allows to write more high-level specifications for positioning the graphical elements of a visuali- 
sation. While IDPDraw and ASPVIZ require the use of absolute coordinates, Kara additionally supports 
relative positioning and automatic layouting for graph and grid structures. Note that technically, the former 
is realised using ASP, by guessing positions of the individual elements and adding respective constraints to 
ensure the correct layout, while the latter is realised by using a standard graph layouting algorithm which 
is part of the Eclipse framework. In Kara, as well as in IDPDraw, each graphical element has a unique 
identifier that can be used, e.g., to link elements or to set their properties (e.g., colour or font style). That 
way, programs can be written in a clear and elegant way since not all properties of an element have to be 
specified within a single atom. Here, Kara exploits that the latest ASP solvers support function symbols 



IDPDraw has been used for visualisation of the benchmark problems of the second and third ASP competition. 




Fig. 8. Visualisation of a coloured graph. 



that allow for generating new identifiers from terms of the interpretation to visualise. IDPDraw does not 
support function symbols. Instead, for having compound identifiers, IDPDraw uses predicates of variable 
length (e.g., idp_polygon(idi,id,2, ...)). A disadvantage of this approach is that some solvers, like DLV, do 
not support predicates of variable length. ASPVIZ does not support identifiers for graphical objects. 

The support for a z-axis to determine which object should be drawn over others is available in Kara 
and IDPDraw but missing in ASPVIZ. Both Kara and ASPVIZ support the export of visualisations as 
vector graphics in the SVG format, which is not possible with IDPDraw. A feature that is supported by 
ASPVIZ and IDPDraw, however, is creating animations which is not possible with Kara so far. 

Kara and ASPVIZ are written in Java and depend only on a Java Virtual Machine. IDPDraw, on 
the other hand, is written in C++ and depends on the qt libraries. Finally, Kara is embedded in an IDE, 
whereas ASPVIZ and IDPDraw are stand-alone tools. 

A related approach from software engineering is the Alloy Analyzer, a tool to support the analysis of 
declarative software models [12]. Models are formulated in a first-order based specification language. The 
Alloy Analyzer can find satisfying instances of a model using translations to SAT. Instances of models 
are first-order structures that can be automatically visualised as graphs, where the nodes correspond to 
atoms from respective signature declarations in the specification, and the edges correspond to relations 
between atoms. Since the Alloy approach is based on finding models for declarative specifications, it can 
be regarded as an instance of ASP in a broader sense. The visualisation of first-order structures in Alloy 
is closely related to the generic visualisation mode of Kara where no dedicated visualisation program is 
needed. Alloy supports filtering predicates and arguments away of the graph. We consider to add such a 
feature in future versions of Kara for getting a clearer generic visualisation. 

5 Conclusion 

We presented the tool Kara for visualising and visual editing of interpretations in ASP. It supports generic 
as well as customised visualisations. For the latter, a powerful language for defining a visualisation by 
means of ASP is provided, supporting, e.g., automated graph layouting, grids of graphical elements, and 
relative positioning. The editing feature is based on abductive reasoning, inferring a new interpretation as 
hypothesis to explain a modified visualisation. In future work, we want to add support for defining input 
and output signatures for programs in SeaLion. Then, the abduction framework of Kara could be easily 
extended such that instead of deriving an interpretation that corresponds to the modified visualisation, one 
can derive inputs for a domain program such that one of its answer sets has this visualisation. 
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A Predefined Visualisation Predicates in Kara 



Atom 


Intended meaning 


vis ellipse [id, height, width) 


Defines an ellipse with specified height and width. 


visrect ( id, height, width) 


Defines a rectangle with specified height and width. 


vispolygon (id,x,y,ord) 


Defines a point of a polygon. The ordering defines in which order 
the defined points are connected with each other. 


visimage(id,path) 


Defines an image given in the specified file. 


visline{id,X\,y\,Xi,yi,z) 


Defines a line between the points (xi, y±) and (x^, 2/2)- 


visgrid ( id, rows, cols, height, width) 


Defines a grid, with the specified number of rows and columns; 
height and width determine the size of the grid. 


visgraph(id) 


Defines a graph. 


vistext(id,text) 


Defines a text element. 


vislabel(idg,id t ) 


Sets the text element id t as a label for graphical element id g . Labels 
are supported for the following elements: visellipse/3, visrect /3, 
vispolygon /4, and visconnect/3. 


visisnode(id n ,id g ) 


Adds the graphical element id n as a node to a graph id g for au- 
tomatic layouting. The following elements are supported as nodes: 

visrect/ 3, visellipse/3, vispolygon / 4, visimage/2. 


visscale(id, height, weight) 


Scales an image to the specified height and width. 


visposition{id,x,y,z) 


Puts an element id on the fixed position (x, y, z). 



visfontfamily(id,ff) 


Sets the specified font ff for a text element id. 


vis f outsize (id, size) 


Sets the font size size for a text element id. 


vis fontstyle (id, style) 


Sets the font style for a text element id to bold or italics. 


vis color (id, color) 


Sets the foreground colour for the element id. 


visbackgroundcolor ( id, color) 


Sets the background colour for the element id. 


visfillgrid(id g ,id c ,row,col) 


Puts element id c in cell (row, col) of the grid id g . 


visconnect (id c ,id gi , id g2 ) 


Connects two elements, id gi and id gs , by a line such that id gi is the 
source and id g2 is the target of the connection. 


vissourcedeco ( id, deco) 


Sets the source decoration for a connection. 


vistargetdeco(id,deco) 


Sets the target decoration for a connection. 


visleft(idi,id r ) 


Ensures that the x-coordinate of idi is less than that of id r . 


visright(id r ,idi) 


Ensures that the .x-coordinate of id r is greater than that of idi. 


visabove(idt,idb) 


Ensures that the y-coordinate of id t is smaller than that of idb- 


visbelow (idi,,idt) 


Ensures that the y-coordinate of idb is greater than that of idt- 


visinfrontof (idi ,idg) 


Ensures that the z-coordinate of irfj is greater than that of • 


vishide(id) 


Hides the element id. 


visdeletable(id) 


Defines that the element id can be deleted in the visual editor. 


viscreatable(id) 


Defines that the element id can be created in the visual editor. 


vis chang able (id, prop) 


Defines that the property prop can be changed for the element id in 
the visual editor. 


vispossiblegridvalues (id,id e ) 


Defines that graphical element id e is available as possible grid value 
for a grid id in the visual editor. 
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